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Abstract 

This  paper  describes  on-going  research  on  a  proce¬ 
dure  for  the  verification  of  hybrid  system  controllers  im¬ 
plemented  via  HyBrithms’  Mutiple  Agent  Hybrid  Control 
Architecture  which  executes  the  Kohn-Nerode  procedure 
for  the  on-line  extraction  of  real-time  controls.  It  is  an 
automated  static  verification  technique  based  on  the  con¬ 
struction  of  an  Intersection  Unification  Automaton  (lUA). 
We  discuss  an  essential  step  of  this  verification  technique, 
namely,  a  procedure  to  verify  that  the  controller  design 
generated  by  an  agent  in  MAHCA  meets  the  requirements 
established  for  that  agent.  The  paper  descibes  the  func¬ 
tionality  of  the  procedure  and  illustrates  it  with  an  exam¬ 
ple. 

1.  Introduction 

This  paper  describes  on-going  research  on  a  proce¬ 
dure  for  the  verification  of  hybrid  system  controllers  im¬ 
plemented  via  HyBrithms’  Multiple  Agent  Hybrid  Control 
Architecture  [11]  which  executes  the  Kohn-Nerode  pro¬ 
cedure,  [8,  10,  12,  13,  14,  15],  for  the  on-line  extraction 
of  real-time  control.  It  is  2ui  automated  static  verifica¬ 
tion  technique  based  on  the  construction  of  2m  Intersec¬ 
tion  Unification  Automaton  (lUA).  Given  a  hybrid  system 
controller  generated  by  a  MAHCA  agent  and  a  set  of  con¬ 
trol  specifications  for  its  desired  behavior,  the  proposed 
verification  procedure  builds  an  lUA  constructed  by  an 
automata  operation  on  two  Inference  automata:  the  au¬ 
tomaton  encoding  the  specifications  and  the  control  au- 
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tomaton  constructed  by  the  inferencer  of  the  agent  [11]. 
The  ultimate  goal  of  our  research  is  to  develop  a  verifi¬ 
cation  procedure  to  verify  a  MAHCA  distributed  imple¬ 
mentation  to  a  set  of  global  requirement  specifications.  In 
this  paper  we  discuss  an  essential  step,  namely,  a  proce¬ 
dure  to  verify  that  the  controller  design  generated  by  an 
agent  in  MAHCA  meets  the  requirements  established  for 
that  agent.  The  paper  descibes  the  functionality  of  the 
procedure  and  illustrates  it  with  an  example, 

2.  The  outline  of  the  verification 
procedure 

The  verification  procedure  that  we  propose  is  based  on 
the  construction  of  a  proof  system  in  the  domain  in  which 
a  hybrid  controller  generated  by  an  agent’s  inferencer  and 
the  specifications  axe  represented  by  nondetermistic  finite 
state  automata. 

The  proof  system  is  very  simple.  It  is  based  on  the 
comparison  of  the  behavior  of  the  two  automata  in  the 
domain:  one  representing  the  execution  automaton  of  an 
agent’s  inference  automaton  [11]  (in  the  domain  of  the 
proof  system)  and  the  other  representing  the  specifica¬ 
tions.  In  the  remaining  paxt  of  this  section  we  shall  give 
an  outline  of  our  proof  procedure. 

Consider  a  control  automaton  with  requirements.  Let 
A  be  the  behavior  associated  with  the  agent  and  let  B  be 
the  behavior  of  the  automaton  representing  the  require¬ 
ments,  The  proof  system  has  to  show  that  for  any  inputs 
to  A  ,  the  behavior  R  ,  defined  by 

R^iAn^iBYY  (1) 

is  empty  where  n^i  is  a  binary  operation  on  the  universe 
of  behaviors  such  that  if  Z  ^  Xn^Y  for  behaviors  X  and 
Y  in  the  universe  of  behaviors  U,  then  Z  is  the  behavior 
common  to  X  and  Y.  In  (1),  (Y  is  a  unary  operation  on 
the  universe  of  behaviors  such  that  if  Z  =  (X)^,  then  Z  is 
the  logical  complement  of  the  behavior  X  .  hituitively,  if 
X  is  a  behavior  representing  a  set  of  requirements,  (X)^ 


represents  the  set  of  .behaviors  which  violate  those  require¬ 
ments.  Finally  in  (1),  ()‘  is  a  unary  operation  on  U  such 
that  if  Z  =  (Xy,  then  Z  represent  the  smallest  behavior 
equivalent  to  X. 

3.  Verification  automaton 

A  verification  automaton  is  an  object 
A  =  (Q,  X,  I,  T, Y,  Z,  $, <5,  a,  /?)  where 

1)  Q  is  a  set  of  states. 

2)  X  is  the  domain  set. 

3)  /  is  the  set  of  initial  states. 

4)  T  is  the  set  of  terminal  states. 

5)  Y  is  the  input  domain. 

6)  Z  is  the  output  domain. 

7)  $  =  :  X  X}  is  the  instruction  set. 

8)  <J :  Q  X  $  -)•  Q  is  the  state  transition  function. 

9)  a  :  y  ->•  X  is  the  input  function. 

10)  /?  ;  Q  X  $  X  X  Z  is  the  output  function. 

In  addition,  we  make  the  following  assumptions  about 
the  verification  automata. 


actions  under  chattering  composition  [5] 

$-=ur=o^*-  (3) 

Here  =  {A}  with  A  being  the  identity  function  on  X 
so  that  A(a;)  =  X  for  all  x  E  X  and  is  the  set  of  all 
chatering  compositions  with  exactly  k  steps 

()))-•). 

This  corresponds  for  example  to  a  branch  of  the  con¬ 
troller  whose  state  path  in  the  automaton  is  pictured  in 
Figure  1. 

The  iterated  state  transition  S*  is  a  relation  5*  :  Q  x 
Q  ,  defined  recursively  as  follows: 


L  We  ignore  the  sensor  and  goal  domains  which  are 
the  inputs  to  the  control  automaton  A  and  the  output 
domain  which  is  the  set  of  control  actions. 

II.  Each  element  g  E  Q  is  a  controller  state.  The 
controller  states  corresponds  to  relations  which  the 
system  must  satisfy  after  the  excution  of  the  control 
action  which  is  issued  in  the  controller  state,  see  [5]. 

III.  The  relation  5  encodes  the  transition  between 
relations  to  be  satisfied.  If  g  is  the  current  controller  state 
which  implements  action  E  $  and  x  E  X  is  the  current 
state  of  the  system,  then  S{qj({>i{x))  =  Qnext  where  qnext 
is  the  label  of  the  next  relation  to  be  satisfied. 

IV.  If  g  E  Q  is  an  element  of  /,  we  say  that  q  is 
an  initial  relation  label. 

V.  If  g  E  Q  is  an  element  of  T,  we  say  that  g  is  a 
success  relation  label. 

VI.  The  output  function  /3  satisfies  the  following: 

A  /  if  g  E  T, 

0{Q,<l>i{^))  -  I  j_  if  otherwise  ^  ^ 

That  is,  if  g  is  the  label  of  the  control  (f>i{x)  and  g  is 
terminal,  then  the  output  function  gives  the  value  of  the 
control  action.  Otherwise  the  output  function  generates 
the  empty  symbol  J.. 

An  iterated  state  transition  represents  a  sequence  of 
two  or  more  consecutive  state  transitions  coresponding 
to  a  control  action  satisfying  the  composite  of  the  cor¬ 
responding  relations.  Let  be  the  monoid  of  all  control 


5*(g.A) 

=  Q 

6’{q,<i>) 

=  <t>  Vfli.  e  $ 

5*{q,  (f/jj) 

=  S*{5{q,<t>),u) 

W4>  6  e 

or 

=  5{5^iq,w),<i>) 

V(/>  e  e  # 

The  state  behavior  of  the  automaton  defines  a  func¬ 
tion  Aq  X  X  X  each  g  E  Q  by 


if  5*{q,uj)  E  T 
if  otherwise. 


(4) 


Thus  any  control  action  applied  to  an  x  in  the  domain  X 
yields  a  result  that  is  still  in  the  domain. 

The  output  behavior  function  is  denoted  by  OAq  and 
maps  the  Y  x  where  Y  is  the  input  set  to  the  output 
set  Z  by 

OA,(y)=/3(A,(a;,a(y)).  (5) 

Given  an  automaton  A  =  (Q,  X,  J,  T,  Z,  $,  a,  )3),  the 
accessible  automaton  A^  associated  with  A  is  defined  by 
the  following  algorithm  in  which  Qo*  Qi>  •  •  •  represent  sets 
of  states,  g'  represents  a  new  state,  g  represents  a  previ¬ 
ous  state,  Qo  =  J,  Qi^i  =  {g'  e  Q  -  Qi|3g  €  Qi30  E 
^(<^(^>0)  =  Q^)}y  and  with  the  termination  criterion  that 
if  Qk  =  0,  then  Qk+p  =  0  for  all  p  >  0. 

This  cJgorithm  defines  a  sequence  of  pairwise  disjoints 
sets  of  states  Qo>  Qi?  •  •  •  such  that  each  state  set  Qi+i  rep¬ 
resents  all  states  g'  that  can  only  be  reached  from  previous 
state  g  E  Qj.  Any  states  that  cannot  be  reached  from  a 
previous  state  are  considered  dead  code.  The  algorithm 
terminates  when  no  new  states  are  defined  from  previous 
states. 


Define  the  accessible  state  set  to  be  set  of  states 
that  can  be  reached  from  some  initial  state  q  ^  I  aJid 
define  the  accessable  terminal  state  set  (or  the  set  of  ter¬ 
minal  state  accessible  from  /)  T®  by  i  T®  =  T  fl 
We  then  define  the  accessible  automaton  A®  by  A®  — 

where  7“  =  n  /  =  / 
and  is  the  restriction  of  <5  to  x  Note  that  if 
IQI  =  n,  then  since  the  sets  Qi  are  pairwise  disjoint  we 
have  Qn  =  0  •  Thus  we  have  an  a  priori  bound  on  the 
length  of  the  procedure. 

Given  the  automaton  A,  a  coaccessible  automaton  can 
be  built  in  a  similar  manner.  To  do  this,  we  need  to 
define  the  reversal  automaton  A’*.  The  idea  is  simple. 
We  want  a  state  path  of  the  reversal  automaton  to  the 
state  path  of  A  except  that  we  want  to  traverse  the  state 
path  backwards.  Thus  if  A  =  (QjX,  J,r,y,Z,  a,/3), 
then  A"  =  (Q,X,7^^^y,Z,$,<5^a,/3)  where  F  =  T, 
=  7,  and  S^{q,  (t>)  =  g'  if  5{q\  0)  =  g  Vg,  g'  €  e  $ 
An  automaton  state  g  G  Q  is  said  to  be  coaccessible  if  and 
only  if  its  g  is  is  accessible  in  the  reversal  automaton.  We 
then  define  the  coaccessible  automaton  by 


The  intersection  of  two  automata  is  performed  by  tak¬ 
ing  the  cross  product  of  the  states  (Q),  the  initial  states 
(7),  and  the  terminal  states  (T)  (the  cross  product  gener¬ 
ates  all  possible  pairs  of  states  between  the  two  automa¬ 
tons)  and  keeping  only  the  state  transitions  in  the  inter¬ 
section  automaton  where  the  state  transitions  in  the  two 
original  automatons  are  defined  and  the  two  state  transi¬ 
tions  unify.  Two  instructions  unify  if  one  can  be  used  to 
implement  the  other.  For  example,  an  if  statement  can  be 
implemented  with  a  while-do  loop. 

In  summary,  the  verification  is  performed  by  repre¬ 
senting  two  different  descriptions  of  a  program,  such  as 
the  program  code  and  its  requirements,  as  automatons  and 
then  intersecting  the  two  automatons.  In  the  intersection 
process,  all  possible  pairs  of  states  in  the  two  automatons 
are  examined  and  the  state  pairs  that  fail  to  unify  are 
discarded.  All  states  that  are  not  members  of  a  unified 
state  pair  are  identified.  Leftover  states  from  the  program 
automaton  represent  code  that  exceeds  the  requirements. 
Leftover  states  from  the  requirements  automaton  repre¬ 
sent  requirements  that  were  not  implemented. 


That  is,  the  coaccessible  automaton  A^  is  obtained  by  re¬ 
versing  automaton  A,  computing  the  accessible  automa¬ 
ton  of  the  reversal  automaton  ,  and  then  reversing  the 
resulting  automaton.  Finally,  given  an  automaton  A,  the 
trim  automaton  A^  associated  with  A  is  defined 

A*  =  (A“)"  =  (A")“. 

That  is,  to  compute  the  trim  automaton  A*,  we  compute 
the  accessible  automaton  A^  and  compute  for  it  the  coac¬ 
cessible  automaton  of  A®.  The  most  important  property 
of  a  trim  automaton  is  that  every  state  path  segment  is 
a  path  from  an  initial  to  a  terminal  state.  Computing 
the  trim  automaton  gets  rid  of  dead  code  automatically 
(this  includes  code  that  is  unnecessary,  which  doesn’t  con¬ 
tribute  to  the  output). 


4.  Intersection  Unification  Automaton 

Given  automata 

Ai  =  {QuX,Ix,TuY,Z,ii,Siaul3i)and  (6) 

A2  =  {Q2,X,l2,T2,Y,Z,i2,S2,a2,02),  (7) 

the  intersection  unification  automaton,  denoted  by  i4inA2 
is  defined  as  follows. 


Aifl  A2  =  (Qi  X  Q2,X,Ii  X  l2,Ti  X  T2,Y,Z,^i,5iai,Pi) 

where  Vgi  €  Qi,Vg2  €  Q2»V^i  €  $i,V02  €  ^2> 

i'S{qi,(t>i)),{S2{.q2,<l>2))  if  (*) 

JL  if  otherwise 


5((gi.92),<^)  =  I 


where  (*)  stands  for  “5(gi,0i),(^2(g2)02)  ar®  defined  and 
(pi  unifies  with  <p2^\ 


5.  The  INVERT  Prototype 

The  first  phase  of  the  tool,  the  translated-code  verifi¬ 
cation  tool,  has  been  prototyped  for  a  subset  of  the  XPL 
language.  For  this  phase  of  the  tool,  verification  is  defined 
as  showing  that  the  translated  software  meets  the  require¬ 
ments  established  by  the  source  language  software;  that  is, 
showing  that  the  two  programs  functionally  perform  the 
same  and  their  output  data  undergo  the  same  transitions. 
Since  we  wanted  to  concentrate  on  demonstrating  the  uni¬ 
fication  technique  instead  of  language  parsing  techniques, 
the  prototype  was  developed  for  only  one  language  instead 
of  two.  Therefore,  two  different  programs  written  in  the 
same  language  are  used  to  simulate  the  translated  code. 

This  section  contains  a  functional  description  of  the 
prototype  translated-code  verification  tool.  It  is  described 
in  terms  of  its  software  components  and  their  functional¬ 
ity.  The  next  section  describes  a  sample  execution  of  the 
prototype  tool.  The  prototype  tool  was  developed  on  an 
Sagent  IRAD  project  by  Dan  Strauss,  Robert  St.  John, 
and  Holly  Gibbons  using  the  verification  theory  provided 
by  Dr.  Wolf  Kohn. 

Figure  3  illustrates  the  software  components  of  IN¬ 
VERT  and  how  they  interact.  INVERT  consists  of  a 
Parser,  Semantic  Generator,  Trimmer,  and  Unifier.  The 
Parser  and  Semantic  Generator  together  are  abstractly  re¬ 
ferred  to  as  the  Automaton  Generator.  The  Trimmer  and 
Unifier  together  are  abstractly  referred  to  as  the  Automa¬ 
ton  Manipulator.  In  the  prototype  INVERT,  the  Unifier 
is  executed  separately  from  the  other  components. 

All  components  of  the  prototype  INVERT  were  origi¬ 
nally  coded  in  the  C  Language  Integrated  Production  Sys¬ 
tem  (CLIPS),  an  expert  system  tool  developed  by  the  Soft¬ 
ware  Technology  Branch  at  NASA  Johnson  Space  Center 


Figure  2:  INVERT  Software  Components. 


(JSC);  however,  some  of  the  components  have  been  con¬ 
verted  to  the  C  language. 

The  Parser  accepts  an  XPL  program  and  produces 
a  parse  tree  based  on  the  syntax  (the  grammar  or  struc¬ 
ture)  of  the  XPL  language.  As  stated  above,  the  INVERT 
prototype  is  implemented  for  a  subset  of  the  XPL  lan¬ 
guage.  The  subset  includes  declarations,  assignments,  if- 
then-else  statements,  loops,  bit  variables,  arrays,  logical 
expressions,  and  arithmetic  expressions.  It  does  not  in¬ 
clude  procedures,  case  statements,  goto  statements,  and 
input/output  statements.  Therefore,  the  programs  ac¬ 
cepted  by  the  prototype  tool  are  simple,  procedural,  non- 
real-time  XPL  programs  with  no  input  or  output  state¬ 
ments.  The  Parser  was  developed  using  lex  and  yacc, 
the  UNIX  lexical  analyzer  and  parser,  respectively,  and 
is  based  on  the  Backus-Naur  form  (BNF)  of  the  XPL  lan¬ 
guage. 

The  Semantic  Generator  takes  the  parse  tree  gener¬ 
ated  by  the  Parser  and  uses  the  operational  semantic  rules 
of  XPL  to  produce  a  locally  finite  automaton  describing 
all  of  the  program’s  states  for  a  given  set  of  inputs.  Phys¬ 
ically,  the  automaton  is  a  collection  of  data  structures,  or 
objects,  that  describe  the  order  of  the  program  instruc¬ 
tions  executed  amd  the  data  contents  changed  after  each 
instruction  is  executed.  Specifically,  a  separate  object  de¬ 
scribes  each  data  item,  each  instruction,  and  each  program 
state.  The  automaton  serves  as  input  to  the  Trimmer  and 
the  Unifier.  The  operational  semantic  rules  of  XPL,  which 
define  the  meaning  of  the  XPL  statements,  were  obtained 
from  the  XPL  language  specification;  test  cases  were  used 
to  determine  the  semantics  when  the  specification  lacked 
sufficient  detail. 

The  Trimmer  accepts  the  automaton  and  identifies  in 


it  the  unnecessary  code.  Note  that  eliminating  unneces¬ 
sary  code  does  not  change  the  functionality  of  the  pro¬ 
gram.  The  code  must  be  trimmed  to  maximize  the  effi¬ 
ciency  of  the  verification  -  only  necessary  code  should  be 
verified.  The  Trimmer  in  the  prototype  INVERT  prompts 
the  user  for  a  list  of  output  variables  for  the  program,  then 
traverses  the  program  backwards  and  builds  a  list  of  vari¬ 
ables  that  contribute  to  the  output.  Initially,  only  the  out¬ 
put  variables  are  on  the  list.  As  the  traversal  continues, 
the  list  grows  to  include  all  important  intermediate  vari¬ 
ables.  If  a  program  statement  does  not  alter  any  variables 
on  the  list,  then  it  is  considered  unnecessary  and  is  flagged 
as  such  in  the  automaton.  The  prototype  Trimmer  does 
not  yet  flag  dead  code  because  dead  code  is  identifiable 
in  the  automaton  generated  by  the  Semantic  Generator, 
which  marks  each  statement  as  it  is  executed. 

The  Unifier  takes  two  automatons  produced  by  sepa¬ 
rate  runs  of  the  Automaton  Generator  and  a  list  of  desired 
output  variables  for  one  of  the  programs  and,  by  compar¬ 
ing  the  states  of  the  two  automatons,  tells  whether  they 
unify.  Unification  is  defined  as  the  output  data  undergo¬ 
ing  the  same  transitions  in  both  automatons.  The  Unifier 
uses  variable  substitution  to  map  corresponding  variables 
in  the  two  automatons,  so  the  two  programs  can  use  dif¬ 
ferent  names  for  the  same  variables.  The  Unifier  then 
generates  a  Cartesian  product  of  the  output  states  from 
the  first  automaton  with  the  output  states  from  the  sec¬ 
ond  automaton,  and  examines  every  pair  of  output  states 
to  locate  the  pairs  that  unify  (output  states  correspond 
to  statements  that  modify  output  variables).  Two  output 
states  unify  if  their  variables  substitute,  they  are  assigned 
the  same  value,  and  the  variables  they  reference  have  the 
same  value.  Two  automatons  unify  if  and  only  if  all  out¬ 
put  states  unify.  The  Unifier  produces  a  Boolean  result 
specifying  whether  or  not  the  two  automatons  unify,  and, 
if  they  do  not  unify,  a  list  of  the  states  and  variables  that 
do  not  unify.  K  the  two  automatons  unify,  they  are  con¬ 
sidered  verified. 

For  example,  suppose  Automatonl  and  Automaton 
2  have  states  representing  declarations  and  executable 
statements.  The  states  representing  declarations  in  Au¬ 
tomatonl  do  not  unify  with  states  representing  executable 
statements  in  Automaton2  so  those  pairs  of  states  are  dis¬ 
carded.  Pairs  of  states  that  represent  similar  variable  dec¬ 
larations  or  similar  executable  statements  in  the  two  au¬ 
tomatons  may  unify. 

6.  Example 

Figure  4  illustrates  the  INVERT  verification  process 
performed  by  the  prototype  tool.  INVERT  generates  a 
trimmed  automaton  for  both  the  first  program,  labeled 
Sourcel,  and  the  second  program,  labeled  Source2.  Un¬ 
necessary  code  identified  by  the  Trimmer  is  based  on  the 
list  of  desired  outputs  provided  for  each  program.  The  two 
automatons  are  then  subjected  to  the  INVERT  unification 


Figure  3:  INVERT  Verification  Process. 


process.  Since  the  Unifier  is  still  executed  separately  from 
the  other  components  in  the  prototype  INVERT,  the  list 
of  desired  outputs  must  again  be  specified.  The  Unifier 
reports  a  Boolean  result  as  to  whether  or  not  the  two  pro¬ 
grams  unify,  and,  if  they  do  not  unify,  the  Unifier  also  re¬ 
ports  the  states  and  variables  in  each  program  that  failed 
to  unify. 

Ultimately  the  translated-code  version  of  INVERT 
will  verify  software  translated  from  one  language  to  an¬ 
other.  However,  as  stated  in  Section  4,  the  prototype 
tool  only  accepts  simple,  procedural,  non-real-time  XPL 
programs  with  no  input  or  output  statements.  Therefore 
the  verification  capability  of  the  prototype  INVERT  was 
demonstrated  by  providing  as  input  two  different  XPL 
programs  that  implement  the  same  basic  design  using 
slightly  different  language  constructs.  Figure  5  lists  a  pro¬ 
cedure  named  Bubblel  and  a  procedure  named  Bubble2. 

Both  procedures  sort  an  array  of  10  numbers  in  as¬ 
cending  order  using  a  bubble  sort  algorithm.  However, 
Bubblel  uses  nested  counted  loops  while  Bubble2  uses 
nested  while  loops.  In  addition,  Bubble2  has  several  lines 
of  unnecessary  and  dead  code,  as  indicated  by  the  com¬ 
ments  in  the  program. 

INVERT  is  executed  for  both  Bubblel  and  Bubble2  to 
generate  trimmed  automatons  for  each.  The  desired  out¬ 
put  for  procedure  Bubblel  is  the  array  A,  and  the  desired 
output  for  procedure  Bubble2  is  array  Arr.  The  Bubble2 
automaton  has  the  unnecessary  and  dead  code  flagged. 


BUBBLE  1 


•  BUBBLE  SORT  ALGORITHM  * 

•  USING  COUNTED  LOOPS  * 

•  TO  SORT  10  NUMBERS  • 

•DC  =  D«*d  Code  • 


1  DECLARE  A(9)  BIT(8) 

IN1TIAL(3,6,7.1,9,0,4,2,5,8) 

2  DECLARE(TEMP,  I,  J)  BIT(8) 

3  DO  I  =  0  TO  8; 

4  DO  J  =  1+1  TO  9 

5  IF  A(J)  <  A(J) 

6  THEN  DO; 

7  TEMP  =  A(J); 

8  A(J)  =  A(I)5 

9  A(I)  sr  TEMP; 

10  END; 

11  END; 

12  END; 

13  IF  A(9)  <  A(0) 

14  THEN  TEMP  =  0;  •  DC  • 

15  EOF 


BUBBLE  2 


•  BUBBLE  SORT  ALGORITHM  • 

•  WITH  WHILE  LOOPS  • 

•  AND  UNNECESSARY  CODE  8 

•  UC  ^  Unneeeeiaery  Code  • 


1  DECLARE  ARR(9)  BXT(8) 

INITIAL(3,e.7,l,9.0.4.2,5,8) 

2  DECLARE(T,  T2,  I,  J)  BIT(8) 

3  DECLARE  LENGTH  BIT(8) 

1N1TIAL(9) 

4  J  =s  0;  •UC  • 

5  T2  =  0;  •  UC  8 

6  J  S5  J+  10;  •  UC  • 

7  J  =  J  -  10;  •  UC  • 

8  DO  WHILE  J  <=  LENGTH  -  1; 

9  I  *  J  +  1; 

10  DO  WHILE  1  <=  LENGTH; 

11  IF  ARR(I)  <  ARR(J) 

12  THEN  DO; 

13  T  ARR(I); 

ARR(l)  =  ARR(J); 

15  ARR(J)  =  T; 

16  T2  =T;  •  UC  • 

17  END; 

18  1  =  1  +  1; 

19  T2  =  I;  •  UC  • 

20  I  =  ARR(0)+ARR(9);*  UC  • 

21  I  =  T2;  •  UC  • 

22  END; 

23  J  =  J  +  1; 

24  END; 

25  IF  ARR(9)  <  ARR(O) 

28  THEN  T  =  0;  •  DC  • 

27  EOF 


Figure  4 

After  the  trimmed  automatons  are  generated  for  the 
two  programs,  the  Unifier  is  executed.  The  two  trimmed 
automatons,  Bubblel  and  Bubble2,  and  the  list  of  desired 
outputs  for  Bubblel  (the  array  A)  axe  provided  as  input. 
The  Unifier  performs  variable  substitution  and  determines 
that  variable  A  in  Bubblel  and  variable  Arr  in  Bubble2 
substitute  because  they  are  the  same  type,  their  values  are  ;; 
the  same  in  the  first  state  and  the  last  state,  and  they  do 
not  substitute  with  emy  other  variables.  The  Unifier  then 
performs  unification  on  all  the  program  states.  It  deter¬ 
mines  that  the  two  programs  unify  because  all  of  their 
states  unify.  Two  states  unify  if  the  variables  assigned  in 
that  state  substitute  with  each  other  and  are  assigned  the 
same  value,  and  variables  referenced  in  that  state  have  the 
same  value. 

The  two  programs,  Bubblel  and  Bubble2,  are  consid¬ 
ered  verified  as  performing  the  same  functionally. 


7.  Future  Work 

Currently,  the  prototype  tool  can  only  statically  verify 
software  that  uses  the  same  language,  same  basic  design, 
similar  variables,  and  same  set  of  inputs  for  desired  out¬ 
puts.  Future  work  on  the  translated-code  verification  tool 
includes  expanding  the  prototype  to  handle  two  full  lan¬ 
guages  and  adding  the  following  capabilities:  verify  soft¬ 
ware  with  variable  inputs  as  opposed  to  fixed  inputs,  verify 
different  algorithms  that  perform  the  same  function,  and 
verify  real-time  code  and  hierarchical  code.  In  addition, 
cosmetic  enhancements  such  as  an  easy-to-use  graphical 
user  interface  are  needed  to  make  the  verification  tool  user 
friendly.  A  method  of  representing  requirements  and  spec¬ 
ifications  in  an  automaton  must  be  developed  before  the 
translated-code  verification  tool  can  be  expanded  into  a 
code-to-requirements  verification  tool. 
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